Cisco Router OSPF Design and Implementation Guide
William Parkhurst, PhD, CCIE
 $54.95  0-07-048626-3
Backward Forward
Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13

Reserve your copy at a
Beta Bookstore near you!
Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Chapter 8

Configuring RIP

Introduction

How do I get to San Jose? Practice, practice, practice. The only successful method that I have found for becoming proficient with routers and preparing for the CCIE exam is hands-on experience. In this chapter and the chapters to follow I strongly recommend that you have at lest two routers available so you can implement all of the configurations that will be discussed. These routers do not have to be anything fancy. All that is required is a current version of the Cisco IOS © and a way to connect the two routers, either with ethernet or synchronous serial. Configure the routers as discussed in the text and try any variation you can imagine.

RIP Version 1

Figure 8.1. Network configuration for RIP examples.

Router r1 Configuration Router r2 Configuration

hostname r1 hostname r2

enable password cisco enable password cisco

interface Loopback0 interface Loopback0

ip address 172.16.1.1 255.255.255.0 ip address 172.16.4.1 255.255.255.0

interface Loopback1 interface Loopback1

ip address 172.16.2.1 255.255.255.0 ip address 172.16.5.1 255.255.255.0

interface Ethernet0 interface Ethernet0

ip address 172.16.3.1 255.255.255.0 ip address 172.16.3.2 255.255.255.0

As you can see in Figure 8.1 we only need one physical interface on each router. The other networks in the examples that follow will be simulated using loopback interfaces. The first step in configuring RIP is to start the RIP routing process. This is accomplished by entering configuration mode and enabling the RIP process.

r1#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

r1(config)#router rip

r1(config-router)#

The RIP routing process needs to know which networks to advertise. For r1, we want to advertise networks 172.16.1.0, 172.16.2.0, and 172.16.3.0. The network command is used to inform RIP which networks to advertise in the routing updates.

r1(config-router)#network 172.16.1.0

r1(config-router)#network 172.16.2.0

r1(config-router)#network 172.16.3.0

r1(config-router)#^Z

At this point, list the current router configuration to see how we have configured the basic RIP routing process.

router rip

network 172.16.0.0

Why does the configuration show only one network command when we entered three? Remember from chapter 5 that RIP version 1 does not transmit subnet masks in the routing updates. You can only enter major network numbers with the RIP network configuration command. Since all of r1’s attached networks belong to the class B network 172.16.0.0, this is the network that RIP will advertise. The network command also determines which interfaces will send and receive RIP routing updates. Since all of our networks belong to 172.16.0.0 RIP will send and receive updates on all the interfaces. The configuration on r2 will be identical to the configuration of r1.

r2(config-router)#network 172.16.0.0

r2(config-router)#^Z

How many routes will RIP advertise is this situation, one or three? Remember that RIP v1 will only advertise subnets of a major network out on interface if those networks have the same subnet mask as the interface on which they will be transmitted. Since all of our networks have an identical 24-bit subnet mask, RIP will advertise three routes and the receiving router, r2, will assume that all the advertised networks it receives for major network 172.16.0.0 have the same subnet mask as the interface and which the routes were received. To determine if r1 and r2 are exchanging routing updates use the command show IP route on routers r1 and r2.

r1#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route

Gateway of last resort is not set

172.16.0.0/16 is subnetted, 5 subnets

R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:07, Ethernet0

R 172.16.5.0 [120/1] via 172.16.3.2, 00:00:07, Ethernet0

C 172.16.1.0 is directly connected, Loopback0

C 172.16.2.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Ethernet0

r2#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route

Gateway of last resort is not set

172.16.0.0/16 is subnetted, 5 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

R 172.16.1.0 [120/1] via 172.16.3.1, 00:00:22, Ethernet0

R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:22, Ethernet0

C 172.16.3.0 is directly connected, Ethernet0

Notice that r1 and r2 have three directly connected routes and two routes that have been learned from RIP. Each entry in the routing table contains the following information:

This is the minimum configuration required to enable RIP version 1. The IP routing table contains the information necessary for each router to determine how to route a packet to a destination network. For the connected networks the router needs only to forward a packet destined for a host on the network out the directly connected interface. For packets destined for a network not on a directly connected interface the router must determine which interface should be used to forward the packet.

What happens if the subnet masks are not identical? Assume that the two networks on r1, Ethernet 0 and Ethernet 1, will have no more than 14 hosts each. We can use VLSM to sub-subnet network 172.16.1.0 into two networks using a 28-bit subnet mask as shown in figure 8.2.

Router r1 configuration changes

interface Loopback0

ip address 172.16.1.17 255.255.255.240

interface Loopback 1

ip address 172.16.1.33 255.255.255.240

How will this affect the RIP updates? If we examine the routing table for r2 we see that the new sub-subnetted routes do not appear. The clear ip route * command is used because RIP will remember the old routes for four minutes. This command will clear the IP routing table and force a routing table update to we can see the affect of the router configuration changes.

r2#clear ip route *

r2#show ip route

172.16.0.0/16 is subnetted, 3 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Ethernet0

R1 will not advertise networks 172.16.1.16 and 172.16.1.32 out network 172.16.3.0 since the subnet masks for these networks are unequal. If RIP v1 is going to be deployed on a network than the networks that you want to advertise must all have the same subnet masks if they are contained in the same major network number. For this example the major network number is 172.16.0.0. What if these sub-subnetted networks use a different major subnet number, 173.16.0.0, as shown in figure 8.3?

Router r1 configuration changes

interface Loopback0

ip address 173.16.1.17 255.255.255.240

interface Loopback 1

ip address 173.16.1.33 255.255.255.240

router rip

network 172.16.0.0

network 173.16.0.0

r2# clear ip route *

r2#show ip route

172.16.0.0/16 is subnetted, 3 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Ethernet0

R 173.16.0.0/16 [120/1] via 172.16.3.1, 00:00:14, Ethernet0

Notice that r1 is advertising network 173.16.0.0 enabling r2 to be able to reach the two 173.16 networks on r1. The subnet mask is different that the mask used for the 172.16 network, but since these are different major network numbers, RIP will advertise them. Also notice that RIP version 1 automatically summarizes the network 173.16.0.0. What happens if we assign networks for the sub-subnetted network 173.16.0.0 on r2 (Figure 8.4).

Figure 8.4. Using VLSM on routers r1 and r2 on a different major network.

Router r2 configuration changes

interface Loopback0

ip address 173.16.1.49 255.255.255.240

interface Loopback 1

ip address 173.16.1.65 255.255.255.240

router rip

network 172.16.0.0

network 173.16.0.0

The routing table for r2 now contains

r2#clear ip route *

r2#show ip route

172.16.0.0/16 is subnetted, 1 subnets

C 172.16.3.0 is directly connected, Ethernet0

173.16.0.0/16 is subnetted, 2 subnets

C 173.16.1.48 is directly connected, Loopback0

C 173.16.1.64 is directly connected, Loopback1

Where are the routes to 173.16.1.16 and 173.16.1.32? Recall how the RIP algorithm operates. Router r1 is advertising the route 173.16.0.0 with a hop count of 0 meaning they are directly connected. Router r2 is also directly connected to network 173.16.0.0 so from r2’s perspective it has a better route to 173.16.0.0 and so r2 will ignore the route to 173.16.0.0 that r1 is advertising. Of course this situation is not common but it does illustrate the problems that can occur will RIP v1 since RIP v1 does not advertise subnet information in the routing updates.

This scenario is of course very unlikely. Using an entire class B network for the common network between r1 and r2 does not make sense but does illustrate the behavior of RIP version 1. What would happen if the link between r1 and r2 were on the same major network as the other interfaces (Figure 8.5)?

As long as the subnet mask used is consistent then all the routes will be propagated. Assume we have changed the addresses of the common interfaces to 173.16.1.82/28 (r1) and 173.16.1.81/28 (r2). The routing tables for r1 and r2 will contain routes to all the networks in the configuration.

Router r1 configuration changes Router r2 configuration changes

Interface Ethernet 0 interface Ethernet 0

ip address 173.16.1.81 255.255.255.240 ip address 173.16.1.82 255.255.255.240

router rip router rip

no network 172.16.0.0 no network 172.16.0.0

r1#clear ip route *

r1#show ip route

173.16.0.0/16 is subnetted, 5 subnets

R 173.16.1.48 [120/1] via 173.16.1.81, 00:00:14, Ethernet0

C 173.16.1.32 is directly connected, Loopback1

C 173.16.1.16 is directly connected, Loopback0

C 173.16.1.80 is directly connected, Ethernet0

R 173.16.1.64 [120/1] via 173.16.1.81, 00:00:15, Ethernet0

r2#clear ip route *

r2#show ip route

173.16.0.0/16 is subnetted, 5 subnets

C 173.16.1.48 is directly connected, Loopback0

R 173.16.1.32 [120/1] via 173.16.1.82, 00:00:00, Ethernet0

R 173.16.1.16 [120/1] via 173.16.1.82, 00:00:00, Ethernet0

C 173.16.1.80 is directly connected, Ethernet0

C 173.16.1.64 is directly connected, Loopback1

We will now return to the network of figure 8.1 and examine the other commands available for configuring RIP. These commands can be listed by entering RIP configuration mode and typing a question mark.

r1(config)#router rip

r1(config-router)#?

Router configuration commands:

auto-summary Enable automatic network number summarization

default-information Control distribution of default information

default-metric Set metric of redistributed routes

distance Define an administrative distance

distribute-list Filter networks in routing updates

exit Exit from routing protocol configuration mode

help Description of the interactive help system

neighbor Specify a neighbor router

network Enable routing on an IP network

no Negate a command or set its defaults

offset-list Add or subtract offset from IGRP or RIP metrics

output-delay Interpacket delay for RIP updates

passive-interface Suppress routing updates on an interface

redistribute Redistribute information from another routing protocol

timers Adjust routing timers

validate-update-source Perform sanity checks against source address of routing updates

version Set routing protocol version

Command: auto-summary

Purpose: Automatic for RIP version 1. See section on RIP Version 2

Command: default-information

Purpose:

Command: default-metric

Purpose: A router may be running more that one IP routing protocol (RIP, IGRP, EIGRP or OSPF). Each routing protocol has a different metric, for example RIP has a hop count and OSPF has a dimensionless cost. When injecting routes from one routing protocol to another, the route metric needs to be converted from one protocol to another. The default-metric command is used to perform this conversion. This will be covered in detail in chapter 13.

Command: distance

Purpose: Used to adjust the administrative distance of a route.

r2(config)#router rip

r2(config-router)#distance ?

<1-255> Administrative distance

Enter an administrative distance in the range 1 – 255. The default for RIP is 120. The administrative distance is used when more than one routing protocol is active on a router. For example, if we are running RIP and OSPF and each protocol has a route to the same network the OSPF route would be preferred because OSPF has a lower administrative distance (110) than RIP (120). We can force the RIP route to be chosen by setting the administrative distance to be lower than that for OSPF.

r2(config-router)#distance 130 ?

A.B.C.D IP Source address

<cr>

Choosing <cr> will set the administrative distance to all routes learned from RIP to the number entered, in this case, 130. This can be seen by examining the IP routing table.

r2#show ip route

172.16.0.0/16 is subnetted, 5 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

R 172.16.1.0 [130/1] via 172.16.3.1, 00:00:22, Ethernet0

R 172.16.2.0 [130/1] via 172.16.3.1, 00:00:22, Ethernet0

C 172.16.3.0 is directly connected, Ethernet0

If you want to adjust the administrative distance for a particular IP network use the form

r2(config-router)#distance 130 172.16.0.0 ?

A.B.C.D IP address mask

r2(config-router)#distance 130 172.16.0.0 0.0.255.255 ?

<1-99> IP Standard access list number

<cr>.

Entering <cr> will apply the new administrative distance only to network 172.16.0.0. Notice that the IP address mask is the "reverse" of what is used for a subnet mask. This is the same style used for IP access-lists that were discussed in chapter 7. Since r2 is only learning about network 172.16.0.0 from r1, this has the same effect as applying the administrative distance to all networks learned from RIP. Finally, we can choose the routes that will have their administrative distance modified through the use of an IP access-list. Assume we want to change the administrative distance of the route to 172.16.1.0 to 130 but not affect the route to 172.16.2.0. First we would use the RIP command

r2(config-router)#distance 130 172.16.0.0 0.0.255.255 ?

<1-99> IP Standard access list number

<cr>

r2(config-router)#distance 130 172.16.0.0 0.0.255.255 1 ?

<cr>

r2(config-router)#distance 130 172.16.0.0 0.0.255.255 1

r2(config-router)#^Z

The final step is to create an IP access-list that informs RIP to adjust the administrative distance of 172.16.1.0 but leave the administrative distance of 172.16.2.0 set to 120. Without an access-list but with the distance command shown above, all the routes learned for network 172.16.0.0 will have their administrative distance set to 130 as shown. This is the default behavior.

r2#clear ip route *

r2#sh ip route

172.16.0.0/16 is subnetted, 5 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

R 172.16.1.0 [130/1] via 172.16.3.1, 00:00:01, Ethernet0

R 172.16.2.0 [130/1] via 172.16.3.1, 00:00:01, Ethernet0

C 172.16.3.0 is directly connected, Ethernet0

The access-list needed to adjust only the 172.16.1.0 is

r2(config)#access-list 1 ?

deny Specify packets to reject

permit Specify packets to forward

r2(config)#access-list 1 permit ?

Hostname or A.B.C.D Address to match

any Any source host

host A single host address

r2(config)#access-list 1 permit 172.16.1.0 0.0.0.225 ?

<cr>

r2(config)#access-list 1 permit 172.16.1.0 0.0.0.225

r2(config)#^Z

Notice that we did not have to use a permit any statement at the end of the access-list. A normal IP access-list always has an implicit deny any as the last statement. This is true in this case but the administrative distance is only affected for those routes that have a matching permit statement, so in the case the implicit deny any in the access-list has no effect. The new IP routing table contains

r2#clear ip route *

r2#sh ip route

172.16.0.0/16 is subnetted, 5 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

R 172.16.1.0 [130/1] via 172.16.3.1, 00:00:02, Ethernet0

R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:02, Ethernet0

C 172.16.3.0 is directly connected, Ethernet0


Notice that route 172.16.1.0 is the only route that has an adjusted administrative distance.

If we want to set the administrative distance of 172.16.1.0 to 130 and the administrative distance of 172.16.2.0 to 140, can we use two distance commands with two access lists? Sometimes. When we enter the second distance command under rip configuration, the second distance command will overwrite the first. We can have two distance commands if the major network are different. In summary, we can set the administrative distance of any number of routes on the same major network to any value between 1 and 255, but it has to be the same value. Only those routes that are permitted in the access-list will have their administrative distance modified.

Command: distribute-list

Purpose: Used to filter incoming or outgoing routing updates.

A distribute list is used to delete routes from either incoming or outgoing RIP updates. Assume router r2 wants to delete network 172.16.1.0 that is being advertised by r1. First we need to assign a distribute-list to the RIP process and r2.

We can either use a standard or an extended IP access-list, which gives us many possibilities.

  1. Block the 172.16.1.0 route from any interface using a standard IP access-list.
  2. r2(config)#router rip

    r2(config-router)#distribute-list ?

    <1-199> A standard IP access list number

    r2(config-router)#distribute-list 1 ?

    in Filter incoming routing updates

    out Filter outgoing routing updates

    r2(config-router)#distribute-list 1 in ?

    Ethernet Ethernet IEEE 802.3

    Loopback Loopback interface

    Null Null interface

    <cr>

    r2(config-router)#^Z

    Now create the access-list to block the 172.16.1.0 route.

    access-list 1 deny 172.16.1.0 0.0.0.255

    access-list 1 permit any

    We need the permit any statement in a distribute list otherwise the implicit deny all at the end of the list would filter out all routes learned overall all interfaces. The routing table for r2 now contains

    r2#clear ip route *

    r2#show ip route

    172.16.0.0/16 is subnetted, 4 subnets

    C 172.16.4.0 is directly connected, Loopback0

    C 172.16.5.0 is directly connected, Loopback1

    R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:16, Ethernet0

    C 172.16.3.0 is directly connected, Ethernet0

    Notice that the 172.16.1.0 route from r1 has been filtered. The access-list(s) that are configured for RIP can be seen by listing the configuration or by using the command show ip protocols.

    r2#show ip protocols

    Routing Protocol is "rip"

    Sending updates every 31 seconds, next due in 25 seconds

    Invalid after 181 seconds, hold down 181, flushed after 241

    Outgoing update filter list for all interfaces is not set

    Incoming update filter list for all interfaces is 1

    Redistributing: rip

    Default version control: send version 1, receive any version

    Interface Send Recv Key-chain

    Ethernet0 1 1 2

    Loopback0 1 1 2

    Loopback1 1 1 2

    Routing for Networks:

    172.16.0.0

    Routing Information Sources:

    Gateway Distance Last Update

    172.16.3.1 120 00:00:27

    Distance: (default is 120)

  3. Block the 172.16.1.0 route from any interface using an extended IP access-list.
  4. r2(config)#router rip

    r2(config-router)#distribute-list ?

    <1-199> A standard IP access list number

    r2(config-router)#distribute-list 100 ?

    in Filter incoming routing updates

    out Filter outgoing routing updates

    r2(config-router)#distribute-list 1 in ?

    Ethernet Ethernet IEEE 802.3

    Loopback Loopback interface

    Null Null interface

    <cr>

    r2(config-router)#^Z

    access-list 100 deny ip any 172.16.1.0 0.0.0.255

    access-list 100 permit ip any any

    Notice that the route to block is listed as the destination address in the access-list and not the source address.

  5. Block the 172.16.1.0 route from the ethernet interface using a standard IP access-list.
  6. r2(config)#router rip

    r2(config-router)#distribute-list 1 in ?

    Ethernet Ethernet IEEE 802.3

    Loopback Loopback interface

    Null Null interface

    <cr>

    r2(config-router)#distribute-list 1 in ethernet ?

    <0-1> Ethernet interface number

    r2(config-router)#distribute-list 1 in ethernet 0 ?

    <cr>

    r2(config-router)#distribute-list 1 in ethernet 0/0

    r2(config-router)#^Z

    We can filter routes through a specific interface. If the route advertisement is learned through a different interface it will not be filtered.

  7. Block the 172.16.1.0 route from the ethernet interface using an extended IP access-list.

r2(config)#router rip

r2(config-router)#distribute-list 1 in ?

Ethernet Ethernet IEEE 802.3

Loopback Loopback interface

Null Null interface

<cr>

r2(config-router)#distribute-list 1 in ethernet ?

<0-1> Ethernet interface number

r2(config-router)#distribute-list 1 in ethernet 0 ?

<cr>

r2(config-router)#distribute-list 1 in ethernet 0

r2(config-router)#^Z

For examples 3 and 4 the access-lists did not need to be modified from examples 1 and 2.

To filter outgoing route advertisements the distribute-list would be applied as an outgoing instead of as an incoming list. This also gives us four possibilities for filtering. For the examples assume that r2 wants to block the route to 172.16.4.1 in figure 8.1 so that r1 does not receive it.

1. Block the 172.16.4.0 route going out any interface using a standard IP access-list.

r2(config)#router rip

r2(config-router)#distribute-list 1 ?

in Filter incoming routing updates

out Filter outgoing routing updates

r2(config-router)#distribute-list 1 out ?

Ethernet Ethernet IEEE 802.3

Loopback Loopback interface

Null Null interface

Bgp Border Gateway Protocol (BGP)

Connected Connected

Egp Exterior Gateway Protocol (EGP)

Eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)

Igrp Interior Gateway Routing Protocol (IGRP)

Isis ISO IS-IS

iso-igrp IGRP for OSI networks

ospf Open Shortest Path First (OSPF)

rip Routing Information Protocol (RIP)

static Static routes

<cr>

r2(config-router)#distribute-list 1 out

r2(config-router)#^Z

There are many more selections available for outbound filters than for inbound. These additional choices are covered in chapter 13, Route Redistribution. The access-list for example one would contain

access-list 1 deny 172.16.4.0 0.0.0.255

access-list 1 permit any

The route 172.16.4.0 will not be contained in r1’s routing table after the filter has been applied.

r1#sh ip route

172.16.0.0/16 is subnetted, 4 subnets

R 172.16.5.0 [120/1] via 172.16.3.2, 00:00:03, Ethernet0

C 172.16.1.0 is directly connected, Loopback0

C 172.16.2.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Ethernet0

The applied access-list can be shown using the show ip protocols command.

r2#show ip protocols

Routing Protocol is "rip"

Sending updates every 31 seconds, next due in 7 seconds

Invalid after 181 seconds, hold down 181, flushed after 241

Outgoing update filter list for all interfaces is 1

Incoming update filter list for all interfaces is not set

Redistributing: rip

Default version control: send version 1, receive any version

Interface Send Recv Key-chain

Ethernet0 1 1 2

Loopback0 1 1 2

Loopback1 1 1 2

Routing for Networks:

172.16.0.0

Routing Information Sources:

Gateway Distance Last Update

172.16.3.1 120 00:00:16

Distance: (default is 120)

2. Block the 172.16.4.0 route going out any interface using an extended IP access-list.

r2(config)#router rip

r2(config-router)#distribute-list 100 out

r2(config-router)#^Z

access-list 100 deny ip any 172.16.4.0 0.0.0.255

access-list 100 permit ip any any

  1. Block the 172.16.4.0 route going ethernet interface using a standard IP access-list.
  2. r2(config)#router rip

    r2(config-router)#distribute-list 1 out

    r2(config-router)#distribute-list 1 out Ethernet 0

    r2(config-router)#^Z

    access-list 1 deny 172.16.4.0 0.0.0.255

    access-list 1 permit any

  3. Block the 172.16.4.0 route going ethernet interface using an extended IP access-list.

r2(config)#router rip

r2(config-router)#distribute-list 1 out

r2(config-router)#distribute-list 1 out Ethernet 0

r2(config-router)#^Z

access-list 1 deny 172.16.4.0 0.0.0.255

access-list 1 permit any

Command: Exit

Purpose: Exit router configuration mode and enter global configuration mode.

r2(config)#router rip

r2(config-router)#exit

r2(config)#

Command: Help

Purpose: Get help on help

r2(config)#router rip

r2(config-router)#help

Help may be requested at any point in a command by entering

a question mark '?'. If nothing matches, the help list will

be empty and you must backup until entering a '?' shows the

available options.

Two styles of help are provided:

1. Full help is available when you are ready to enter a

command argument (e.g. 'show ?') and describes each possible

argument.

2. Partial help is provided when an abbreviated argument is entered

and you want to know what arguments match the input

(e.g. 'show pr?'.)

Command: neighbor

Purpose: Specify a neighbor on a non-broadcast network.

For NBMA networks such as X.25 and frame-relay additional configuration information is needed to propagate RIP routing updates. The neighbor command would be needed in order for RIP updates to cross a frame-relay cloud. The neighbor command can be used on a multi-access network (ethernet) in conjunction with the passive-interface command as we shall see.

Command: Network

Purpose: To inform RIP which networks to advertise and out which interfaces to advertise. Any active interface that has an IP address that is contained in the network command will be used to send and receive RIP routing updates.

Command: No

Purpose: Used to negate configuration commands.

The no command is used to undo previous configuration commands. If we decide for example, not to advertise a network, remove a distribution list, or remove an administrative distance modifier we would use the no command.

r1(config)#router rip

r1(config-router)#no network 172.16.0.0

r1(config-router)#no distribute-list 100 out

r1(config-router)#no distance 130

r1(config-router)#^Z

Command: offset-list

Purpose: Add or subtract an offset from IGRP or RIP metrics.

An offset list is used to adjust the metric, or hop count, of routes in incoming or outgoing RIP updates using a standard IP access-list.

  1. Increase the hop count of all incoming RIP routes on r1 by 2.
  2. r1(config)#router rip

    r1(config-router)#offset-list ?

    <0-99> Access list of networks to apply offset (0 selects all networks)

    r1(config-router)#offset-list 1 ?

    in Perform offset on incoming updates

    out Perform offset on outgoing updates

    r1(config-router)#offset-list 1 in ?

    <0-16> Offset

    r1(config-router)#offset-list 1 in 2 ?

    Ethernet Ethernet IEEE 802.3

    Loopback Loopback interface

    Null Null interface

    <cr>

    r1(config-router)#offset-list 1 in 2

    r1(config-router)#^Z

    access-list 1 permit any

    r1#clear ip route *

    r1#show ip route

    172.16.0.0/16 is subnetted, 5 subnets

    R 172.16.4.0 [120/3] via 172.16.3.2, 00:00:02, Ethernet0

    R 172.16.5.0 [120/3] via 172.16.3.2, 00:00:02, Ethernet0

    C 172.16.1.0 is directly connected, Loopback0

    C 172.16.2.0 is directly connected, Loopback1

    C 172.16.3.0 is directly connected, Ethernet0

  3. Increase the hop count of route 172.16.4.0 on r1 by 2.
  4. r1(config-router)#offset-list 1 in 2

    access-list 1 permit 172.16.4.0 0.0.0.255

    r1#show ip route

    172.16.0.0/16 is subnetted, 5 subnets

    R 172.16.4.0 [120/3] via 172.16.3.2, 00:00:02, Ethernet0

    R 172.16.5.0 [120/1] via 172.16.3.2, 00:00:02, Ethernet0

    C 172.16.1.0 is directly connected, Loopback0

    C 172.16.2.0 is directly connected, Loopback1

    C 172.16.3.0 is directly connected, Ethernet0

  5. Increase the hop count of all outgoing RIP routes from r1 by 2.
  6. r1(config)#router rip

    r1(config-router)#offset-list 1 out ?

    <0-16> Offset

    r1(config-router)#offset-list 1 out 2 ?

    Ethernet Ethernet IEEE 802.3

    Loopback Loopback interface

    Null Null interface

    <cr>

    r1(config-router)#offset-list 1 out 2

    r1(config-router)#^Z

    r2#show ip route

    172.16.0.0/16 is subnetted, 5 subnets

    C 172.16.4.0 is directly connected, Loopback0

    C 172.16.5.0 is directly connected, Loopback1

    R 172.16.1.0 [120/3] via 172.16.3.1, 00:00:01, Ethernet0

    R 172.16.2.0 [120/3] via 172.16.3.1, 00:00:01, Ethernet0

    C 172.16.3.0 is directly connected, Ethernet0

    Applied offset-lists can be seen by using the show ip protocols command

    r1#show ip protocols

    Routing Protocol is "rip"

    Sending updates every 30 seconds, next due in 25 seconds

    Invalid after 180 seconds, hold down 180, flushed after 240

    Outgoing update filter list for all interfaces is not set

    Incoming update filter list for all interfaces is not set

    Outgoing routes will have 2 added to metric if on list 1

    Redistributing: rip

    Default version control: send version 1, receive any version

    Interface Send Recv Key-chain

    Ethernet0 1 1 2

    Loopback0 1 1 2

    Loopback1 1 1 2

    Routing for Networks:

    172.16.0.0

    Routing Information Sources:

    Gateway Distance Last Update

    172.16.3.2 120 00:00:11

    Distance: (default is 120)

  7. Increase the hop count of route 172.16.1.0 that is advertised by r1 by 2.

access-list 1 permit 172.16.1.0 0.0.0.255

r2#sh ip route

172.16.0.0/16 is subnetted, 5 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

R 172.16.1.0 [120/3] via 172.16.3.1, 00:00:12, Ethernet0

R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:12, Ethernet0

C 172.16.3.0 is directly connected, Ethernet0

Command: passive-interface

Purpose: Suppress routing updates on an interface.

The passive-interface command stops routing updates from being sent out an interface but routing updates received on a passive-interface will still be received and processed. For example, if the 172.16.3.1 interface of r1 in figure 8.1 is made passive, r2 will not receive routing updates from r1 (because they are not being sent) but r1 will still receive routing updates from r2.

r1(config)#router rip

r1(config-router)#passive-interface Ethernet 0

r1(config-router)#^Z

r1#clear ip route *

r1#sh ip route

172.16.0.0/16 is subnetted, 5 subnets

R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:13, Ethernet0

R 172.16.5.0 [120/1] via 172.16.3.2, 00:00:13, Ethernet0

C 172.16.1.0 is directly connected, Loopback0

C 172.16.2.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Ethernet0

r2#sh ip route

172.16.0.0/16 is subnetted, 3 subnets

C 172.16.4.0 is directly connected, Loopback0

C 172.16.5.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Ethernet0

RIP version 1 normally sends routing updates as a broadcast on an ethernet network which all hosts must process. To prevent broadcasts the passive-interface command can be used in conjunction with the neighbor command. If we want router r1 in Figure 8.1 to send routing updates to a unicast address we can use the following configuration:

Router rip

Passive-interface ethernet 0

Neighbor 172.16.3.2

Command: redistribute

Purpose: Redistribute information from another routing protocol.

This command is covered in chapter 13, Protocol Redistribution.

Command: timers

Purpose: Adjust routing timers.

The RIP timers can be viewed by using the command show ip protocols and shown below.

r2#show ip protocols

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 0 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Redistributing: rip

Default version control: send version 1, receive any version

Interface Send Recv Key-chain

Ethernet0 1 1 2

Loopback0 1 1 2

Loopback1 1 1 2

Routing for Networks:

172.16.0.0

Routing Information Sources:

Gateway Distance Last Update

172.16.3.1 120 00:13:12

Distance: (default is 120)

The update timer (30 seconds) is the time between routing updates sent out of an interface. Routes are invalid after 180 seconds. This means that if a known route is not received within 180 seconds of the last advertisement for this route, the route will be declared invalid. The hold down time is the time that a route will remain in the routing table before a new advertisement for that route will be accepted by the router. The flush time is the amount of time that must expire before a route is removed from the routing table if no routing updates for this route have been received. One timer value that does not appear in the list is the sleep time. The sleep time is the amount of time a RIP routing update will be delayed before transmission nd is measured in milliseconds.

In most cases, you should probably never adjust the RIP timers. They have been selected to provide optimum performance form the protocol. But if you must, here is the syntax.

r2(config)#router rip

r2(config-router)#timers ?

basic Basic routing protocol update timers

r2(config-router)#timers basic ?

<0-4294967295> Interval between updates

r2(config-router)#timers basic 31 ?

<1-4294967295> Invalid

r2(config-router)#timers basic 31 181 ?

<0-4294967295> Holddown

r2(config-router)#timers basic 31 181 181 ?

<1-4294967295> Flush

r2(config-router)#timers basic 31 181 181 241 ?

<1-4294967295> Sleep time, in milliseconds

<cr>

r2(config-router)#timers basic 31 181 181 241 10 ?

<cr>

The new timer values can be verified by using the show ip protocols command.

r2#show ip protocols

Routing Protocol is "rip"

Sending updates every 31 seconds, next due in 7 seconds

Invalid after 181 seconds, hold down 181, flushed after 241

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Command: validate-update-source

Purpose: Perform sanity checks against source address of routing updates.

This function is enabled by default. The source address is checked to see if it is a proper address. In figure 8.1, RIP routing updates received by r1 on interface 172.16.3.1 should be received from a RIP router on this network. If the source address is not on the network then the routing update will be rejected. To disable this feature use the no command in conjunction with the validate-update source command.

r1(config)#router rip

r1(config-router)#no validate-update-source

Command: Version

Purpose: Set routing protocol version

RIP can be configured as version 1 (default) or version 2. This command is used to select the RIP version. The current value can be seen by examining the configuration or by using the show ip protocols command.

r2(config)#router rip

r2(config-router)#version ?

<1-2> version

r2(config-router)#version 1 ?

<cr>

or

r2(config-router)#version 2

The default behavior of RIP can be seen by executing the show ip protocols command.

r2#show ip protocols

Default version control: send version 1, receive any version

Interface Send Recv Key-chain

Ethernet0 1 1 2

Loopback0 1 1 2

Loopback1 1 1 2

Notice that when sending RIP routing updates version 1 is used but each interface can receive both version 1 and version 2 formats. If we change the RIP version to 1 then we disable the processing of version 2 packets and if we set the RIP version to 2 we disable the processing of version 1 packets.

r2(config)#router rip

r2(config-router)#version 1

r2#show ip protocols

Interface Send Recv Key-chain

Ethernet 1 1

Loopback0 1 1

Loopback1 1 1

r2(config)#router rip

r2(config-router)#version 2

r2#show ip protocols

Interface Send Recv Key-chain

Ethernet0/0 2 2

Loopback0 2 2

Loopback1 2 2

This behavior can be modified on a per interface basis by using the ip rip send version or ip rip receive version command while in interface configuration mode. For example, to enable the ethernet interface on r2 to send version 2 and receive version 1 and 2 we would use

r2(config)#interface Ethernet 0

r2(config-if)#ip rip ?

authentication Authentication control

receive advertisement reception

send advertisement transmission

r2(config-if)#ip rip receive ?

version version control

r2(config-if)#ip rip receive version ?

1 RIP version 1

2 RIP version 2

<cr>

r2(config-if)#ip rip receive version 1 ?

2 RIP version 2

<cr>

r2(config-if)#ip rip receive version 1 2 ?

<cr>

r2(config-if)#ip rip receive version 1 2

r2(config-if)#ip rip send version 2

r2(config-if)#^Z

r2#show ip protocols

Interface Send Recv Key-chain

Ethernet0 2 1 2

Loopback0 2 2

Loopback1 2 2

RIP Version 2

Recall from chapter 5 that RIP version 2 includes subnet mask information in the routing updates. This feature allows us to implement the network configuration of figure 8.4, which cannot be handled by RIP version 1. The only change necessary in the configuration is to set the RIP version number to 2.

r1(config)#router rip

r1(config-router)#network 172.16.0.0

r1(config-router)#network 173.16.0.0

r1(config-router)#version 2

r1(config-router)#^Z

r2(config)#router rip

r2(config-router)#network 172.16.0.0

r2(config-router)#network 173.16.0.0

r2(config-router)#version 2

r2(config-router)#^Z

Another major difference between RIP versions 1 and 2 is that RIP version 2 sends and received routing updates on the multicast address 224.0.0.9 and RIP version 1 uses a broadcast address for routing updates. The final difference between RIP version 1 and 2 is that authentication can be used be routers exchanging RIP routing updates. Authentication is configured through the interface configuration mode using

r1(config)#int Ethernet 0

r1(config-if)#ip rip ?

authentication Authentication control

receive advertisement reception

send advertisement transmission

r1(config-if)#ip rip authentication ?

key-chain Authentication key-chain

mode Authentication mode

r1(config-if)#ip rip authentication key-chain ?

LINE name of key-chain

r1(config-if)#ip rip authentication key-chain cisco ?

LINE <cr>

r1(config-if)#ip rip authentication key-chain cisco

r1(config-if)#ip rip authentication mode ?

md5 Keyed message digest

text Clear text authentication

r1(config-if)#ip rip authentication mode md5 ?

<cr>

or

r1(config-if)#ip rip authentication mode text ?

<cr>

r1(config-if)#ip rip authentication mode text

r1(config-if)#^Z

Clear text authentication sends the authentication key in the clear and can be easily determined by intercepting the RIP routing updates so method is not recommended. The md5 authentication method encrypts the key before transmission and so md5 is the preferred method for route authentication.

We are using the authentication key cisco to validate received routing updates. RIP version 2 routers that are not using the same authentication key will have their routing updates ignored by receiving routers that are using a different key.

When we were using RIP version 1 the 173.16.0.0 remote networks did not appear in the routing tables. With RIP version 2, these remote routes will appear in the routing tables as shown.

r1#show ip route

172.16.0.0/16 is subnetted, 1 subnets

C 172.16.3.0 is directly connected, Ethernet0

173.16.0.0/16 is variably subnetted, 3 subnets, 2 masks

C 173.16.1.32/28 is directly connected, Loopback1

C 173.16.1.16/28 is directly connected, Loopback0

R 173.16.0.0/16 [120/1] via 172.16.3.2, 00:00:23, Ethernet0

r2#show ip route

172.16.0.0/16 is subnetted, 1 subnets

C 172.16.3.0 is directly connected, Ethernet0

173.16.0.0/16 is variably subnetted, 3 subnets, 2 masks

C 173.16.1.48/28 is directly connected, Loopback0

R 173.16.0.0/16 [120/1] via 172.16.3.1, 00:00:06, Ethernet0

C 173.16.1.64/28 is directly connected, Loopback1

Notice that only 1 RIP route appears in the routing table for both routers with a subnet mask of 16 while the directly connected 173.16.0.0 networks show a subnet mask of 28. The RIP version 2 process is automatically summarizing the routes into one route advertisement. This is the default behavior of RIP version 2. If we want both routes to be advertised we must disable route summarization.

r1(config)#router rip

r1(config-router)#network 172.16.0.0

r1(config-router)#network 173.16.0.0

r1(config-router)#version 2

r1(config-router)#no auto-summary

r1(config-router)#^Z

r2(config)#router rip

r2(config-router)#network 172.16.0.0

r2(config-router)#network 173.16.0.0

r2(config-router)#version 2

r2(config-router)#no auto-summary

r2(config-router)#^Z

The router tables for r1 and r2 now contain an entry for each remote network.

r1#show ip route

172.16.0.0/16 is subnetted, 1 subnets

C 172.16.3.0 is directly connected, Ethernet0

173.16.0.0/16 is subnetted, 4 subnets

R 173.16.1.48 [120/1] via 172.16.3.2, 00:00:23, Ethernet0

C 173.16.1.32 is directly connected, Loopback1

C 173.16.1.16 is directly connected, Loopback0

R 173.16.1.64 [120/1] via 172.16.3.2, 00:00:23, Ethernet0

r2#show ip route

172.16.0.0/16 is subnetted, 1 subnets

C 172.16.3.0 is directly connected, Ethernet0

173.16.0.0/16 is variably subnetted, 5 subnets, 2 masks

C 173.16.1.48/28 is directly connected, Loopback0

R 173.16.1.32/28 [120/1] via 172.16.3.1, 00:00:28, Ethernet0

R 173.16.1.16/28 [120/1] via 172.16.3.1, 00:00:28, Ethernet0

R 173.16.0.0/16 [120/1] via 172.16.3.1, 00:01:24, Ethernet0

C 173.16.1.64/28 is directly connected, Loopback1

RIP Version 1 and Version 2 Interoperability

For routers to communicate using RIP they must be able to send and receive the same version. The simplest scenario is to have r1 running RIP version 2 and r2 running RIP version 1. If we examine the protocol configurations for r1 and r2 we can see they the routers will not be able to exchange routes.

r1#show ip protocols

Interface Send Recv Key-chain

Ethernet0 2 2

Loopback0 2 2

Loopback1 2 2

r2#show ip protocols

Interface Send Recv Key-chain

Ethernet0 1 1 2

Loopback0 1 1 2

Loopback1 1 1 2

Router r1 is only sending and receiving version 2 packets. Router r2 is sending version 1 packets but can receive both version 1 and version 2 packets but since r2 is running RIP version 1 the packets from r1 will be ignored. We can configure the routers so even though they are running different version of RIP they can receive each others routing updates. For r2 to see the routes from r1 we need to force r1 to send version 1 packets in addition to the version 2 packets by properly configuring the common interface.

r1(config)#interface Ethernet 0

r1(config-if)#ip rip send version 1 2

r1(config-if)#^Z

Examining the protocol configuration shows that r1 is now sending both version 1 and 2 packets to r2.

r1#show ip protocols

Default version control: send version 2, receive version 2

Interface Send Recv Key-chain

Ethernet0 1 2 2

Loopback0 2 2

Loopback1 2 2

Router r2 is now receiving version 1 packets from r1 and the networks for r1 appear in router r2’s routing table.

r2#show ip route

173.16.0.0/16 is subnetted, 5 subnets

C 173.16.1.48 is directly connected, Loopback0

R 173.16.1.32 [120/1] via 173.16.1.82, 00:00:12, Ethernet0

R 173.16.1.16 [120/1] via 173.16.1.82, 00:00:12, Ethernet0

C 173.16.1.80 is directly connected, Ethernet0

C 173.16.1.64 is directly connected, Loopback1

Router r1 does not see the routes from r2 since r2 is sending version 1 packets. This situation can be overcome by enabling r1 to receive version 1 packets through interface configuration mode.

r1(config)#interface Ethernet 0

r1(config-if)#ip rip receive version 1 2

r1(config-if)#^Z

r1#show ip protocols

Default version control: send version 2, receive version 2

Interface Send Recv Key-chain

Ethernet0 1 2 1 2

Loopback0 2 2

Loopback1 2 2

r1#sh ip route

173.16.0.0/16 is subnetted, 5 subnets

R 173.16.1.48 [120/1] via 173.16.1.81, 00:00:20, Ethernet0

C 173.16.1.32 is directly connected, Loopback1

C 173.16.1.16 is directly connected, Loopback0

C 173.16.1.80 is directly connected, Ethernet0

R 173.16.1.64 [120/1] via 173.16.1.81, 00:00:20, Ethernet0

If you are going to upgrade a RIP version 1 network to a RIP version 2 network then you could just change the version number in router configuration mode to 2 but then the version 1 and version 2 routers cannot communicate. A better solution is to change each router to version 2 and configure the appropriate interfaces on the version 2 routers to be able to send and receive version 1 packets. When all the routers have been upgraded to version 2 then all the interfaces can be set to send and receive only version 2 packets. In this way, routing information will still flow between all the RIP routers during the upgrade process. During this time there will be extra network traffic since the version 2 routers are sending both version 1 and version 2 packets.

Debugging RIP

The network in Figure 8.5 is used to illustrate the RIP debugging commands. There are two commands that can be used for debugging RIP. The first is the command

r1#debug ip rip

Which produces the following console output.

RIP: sending v1 update to 255.255.255.255 via Ethernet0 (173.16.1.81)

subnet 173.16.1.32, metric 1

subnet 173.16.1.16, metric 1

RIP: sending v2 update to 224.0.0.9 via Ethernet0 (173.16.1.81)

173.16.1.32/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.16/28 -> 0.0.0.0, metric 1, tag 0

RIP: sending v2 update to 224.0.0.9 via Loopback0 (173.16.1.17)

173.16.1.48/28 -> 0.0.0.0, metric 2, tag 0

173.16.1.32/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.80/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.64/28 -> 0.0.0.0, metric 2, tag 0

RIP: sending v2 update to 224.0.0.9 via Loopback1 (173.16.1.33)

173.16.1.48/28 -> 0.0.0.0, metric 2, tag 0

173.16.1.16/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.80/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.64/28 -> 0.0.0.0, metric 2, tag 0

RIP: ignored v2 packet from 173.16.1.17 (sourced from one of our addresses)

RIP: ignored v2 packet from 173.16.1.33 (sourced from one of our addresses)

RIP: received v1 update from 173.16.1.82 on Ethernet0

173.16.1.48 in 1 hops

173.16.1.64 in 1 hops

Router r1 is sending both version 1 and 2 routing updates. The version 1 updates are being sent to the broadcast address and the version 2 updates are being sent to the multicast address 224.0.0.9. Router r1 is receiving v1 updates from r2 on the ethernet interface and we can see the routes that r2 is sending. This information is useful when one or more routers are not receiving routing updates. The debug output allows us to see exactly what the RIP process is doing and can help to lead us to the misbehaving router. The other RIP debug command is

r1#debug ip rip events

RIP: received v1 update from 173.16.1.82 on Ethernet0

RIP: Update contains 2 routes

RIP: sending v1 update to 255.255.255.255 via Ethernet0 (173.16.1.81)

RIP: Update contains 2 routes

RIP: sending v1 update to 255.255.255.255 via Loopback0 (173.16.1.17)

RIP: Update contains 4 routes

RIP: sending v1 update to 255.255.255.255 via Loopback1 (173.16.1.33)

RIP: Update contains 4 routes

The difference between debug ip rip and debug ip rip events is in the level of detail. Debug ip rip events is a summary of the RIP events whereas debug ip rip contains the information associated with each RIP event.

r1#debug ip rip

RIP protocol debugging is on

r1#

RIP: sending v2 update to 224.0.0.9 via Ethernet0 (173.16.1.81)

173.16.1.32/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.16/28 -> 0.0.0.0, metric 1, tag 0

RIP: sending v2 update to 224.0.0.9 via Loopback0 (173.16.1.17)

173.16.1.32/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.80/28 -> 0.0.0.0, metric 1, tag 0

RIP: sending v2 update to 224.0.0.9 via Loopback1 (173.16.1.33)

173.16.1.16/28 -> 0.0.0.0, metric 1, tag 0

173.16.1.80/28 -> 0.0.0.0, metric 1, tag 0

RIP: ignored v2 packet from 173.16.1.17 (sourced from one of our addresses)

RIP: ignored v2 packet from 173.16.1.33 (sourced from one of our addresses)

When authentication is being used and the keys don’t match or if one routing is using authentication and the other router is not the debugging output would contain

RIP: ignored v2 packet from 173.16.1.82 (invalid authentication).

 

Backward Forward
Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13

Reserve your copy at a
Beta Bookstore near you!
Contact Bet@books
© 1998 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Beta Books | Beta Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New


A Division of the McGraw-Hill Companies
Copyright © 1998 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use; the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.